Univers Mac Interactif 52/Univers Mac Interactif - Issue 52.iso/JOURNAUX/csmp-digest-v3-113

Text File | 1995-11-13 | 64KB | 1,608 lines

C.S.M.P. Digest             Mon, 25 Sep 95       Volume 3 : Issue 113

Today's Topics:

        Deselecting Edit Text Items in Modeless Dialog
        Durnit... mouseMoved events...
        Mac Game Gurus: Need For Errata
        Mac Game Programming Gurus Book
        Mac Help Systems
        Programming MacTCP and Other Forms of Masochism
        Using two different fonts in a dialog box?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroups
comp.sys.mac.programmer.help, csmp.tools and csmp.misc. It is designed for
people who read news semi-regularly and want an archive of the discussions.
If you don't know what a newsgroup is, you probably don't have access to
it. Ask your systems administrator(s) for details. If you don't have access
to news, you may still be able to post messages to the group by using a
mail server like anon.penet.fi (mail [e-mail] for more
information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (David B. Zwiefelhofer)
Subject: Deselecting Edit Text Items in Modeless Dialog
Date: Mon, 04 Sep 1995 11:07:59 -0500
Organization: Berbee Information Networks Corporation

My modeless dialog has a list item as well as several edit text items. As
the user tabs from one edit text item to the next I select the text of the
target item using SelectDialogItemText, e.g. SelectDialogItemText(theDlg,
kRateEditText, 0, 32767). The previous field's text is automatically
deselected.

My problem is that when the next item to be selected is the list item, as
opposed to another text edit item, the last text edit item is not
automatically deselected. How do I manually deselect it?

I can think of a few skanky ways of doing it, but I'd prefer to use the
proper method. I have tried SelectDialogItemText(theDlg, kRateEditText, 1,
0), but this just ends up placing the blinking caret at 0.

Any ideas?

Thanks,

Dave

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Azuma)
Date: Mon, 04 Sep 1995 17:08:27 -0700
Organization: California Institute of Technology, Pasadena

[e-mail] (David B. Zwiefelhofer) wrote:

> My modeless dialog has a list item as well as several edit text items. As
> the user tabs from one edit text item to the next I select the text of the
> target item using SelectDialogItemText, e.g. SelectDialogItemText(theDlg,
> kRateEditText, 0, 32767). The previous field's text is automatically
> deselected.
>
> My problem is that when the next item to be selected is the list item, as
> opposed to another text edit item, the last text edit item is not
> automatically deselected. How do I manually deselect it?

I think the accepted way to handle such a case is to include an editText
dialog item positioned outside the bounds of the window (so it's not
visible). When you switch the selection to a non-text item (such as a
list), use SelectDialogItemText to set the "selection" to it. This will
effectively hide the caret and "disable" typing, as far as the user can
see.

Yes, it may appear to be "skanky", but I think it's generally accepted as
a good method. A similar trick is commonly used to implement password
dialogs.

Good luck,
Dan

                                                                +-+
================================================================| |=======
 \ _____ Daniel Azuma _____ \ "See what love the Father has  +--+ +--+  /
  \ <[e-mail]> \  given us, that we should be  +--+ +--+ /
   \    Caltech CS Student    \  called children of God..."     | |   /
    \  Mac Programming Artist  \            ---1 John 3:1       | |  /
    ============================================================| |===
                                                                | |
                                                                +-+

+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Mon, 04 Sep 1995 18:02:13 -0700
Organization: SPC

In article <DaveZ-0409951107590001@msn_2_13.binc.net>, [e-mail]
(David B. Zwiefelhofer) wrote:

>My problem is that when the next item to be selected is the list item, as
>opposed to another text edit item, the last text edit item is not
>automatically deselected. How do I manually deselect it?

I had the exact same problem. The way I got around it was to process the
tab without letting the Dialog Manager do it.

When you detect a tab, find the next item (or previous item if shift key
is down) you want to tab to by stepping thru each item starting at the
current item + 1 (or current item - 1 if shift key is down), and check if
it's an item you can tab to (it's one your list items, it's an enabled
editText item, etc...).

Once you've figured out which item you want to tab to, determine if you
need to disable the editText items. If an editText item is currently
active and you're tabbing to a list item, you'll want to disable the
editText field and vice versa.

What I did to disable the editText item (really all editText items since
they all use the same TextEdit record) was to first set the selection to
zero (use SelectDialogItemText) then call TEDeactivate on the TEHandle
associated with the dialog (use dialog->textH), then set the dialog's
editField field to -1 (not sure if you have to do the last step but, just
in case).

When you're tabbing from a list item to an editText item, you just have to
call TEActivate on the dialog's textH field and call SelectDialogItemText
to select all the text in the item.

You also have to add a check in your activateEvt handler that checks if a
non-editText item is active and if it is, you have to do the same
de-activating stuff you did when you first de-activated the editText items
since when you get an activateEvt, DialogSelect re-activates the dialog's
editText fields and screws up all your de-activated stuff.

When a non-editText item is active (ie. your list) you also have to make
sure you don't pass any keys to DialogSelect. It will think you're trying
to type in the editText item and display the characters.

You also have to do the same stuff when you detect clicks in your list or
editText items.

I'm not sure if this is the best way to do all this but, it works. I wrote
some routines to simplify this so if you want them, leave me mail.

+++++++++++++++++++++++++++

>From [e-mail] (Patrick Stadelmann)
Date: Thu, 07 Sep 1995 11:20:16 +0100
Organization: University of Neuchatel

In article <DaveZ-0409951107590001@msn_2_13.binc.net>, [e-mail]
(David B. Zwiefelhofer) wrote:

> My modeless dialog has a list item as well as several edit text items. As
> the user tabs from one edit text item to the next I select the text of the
> target item using SelectDialogItemText, e.g. SelectDialogItemText(theDlg,
> kRateEditText, 0, 32767). The previous field's text is automatically
> deselected.
>
> My problem is that when the next item to be selected is the list item, as
> opposed to another text edit item, the last text edit item is not
> automatically deselected. How do I manually deselect it?
>
> I can think of a few skanky ways of doing it, but I'd prefer to use the
> proper method. I have tried SelectDialogItemText(theDlg, kRateEditText, 1,
> 0), but this just ends up placing the blinking caret at 0.

I think SelectDialogItemText(theDlg, kRateEditText, 0, 0) will do the job...

Patrick

--
Patrick Stadelmann <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (David B. Zwiefelhofer)
Date: Fri, 08 Sep 1995 07:58:26 -0500
Organization: Utility Reduction Specialists, Inc.

In article <[e-mail]>,
[e-mail] (Patrick Stadelmann) wrote:

> In article <DaveZ-0409951107590001@msn_2_13.binc.net>, [e-mail]
> (David B. Zwiefelhofer) wrote:
>
> > My problem is that when the next item to be selected is the list item, as
> > opposed to another text edit item, the last text edit item is not
> > automatically deselected. How do I manually deselect it?
> >
>
> I think SelectDialogItemText(theDlg, kRateEditText, 0, 0) will do the job...

Actually, it doesn't. It just leaves a blinking caret in position 0. I had
to get the TEHandle of the dialog and teDeactivate it.

Dave

--
David B. Zwiefelhofer
Utility Reduction Specialists, Inc.
1605 Monroe Street, Suite 110
Madison, WI  53211-2052
[phone]
[phone] FAX

---------------------------

>From [e-mail] (Daniel Azuma)
Subject: Durnit... mouseMoved events...
Date: Tue, 05 Sep 1995 16:23:30 -0700
Organization: California Institute of Technology, Pasadena

Okay, who's experienced in working with mouse regions and mouseMoved events?

Both IM and Toolbox Assistant say that if you pass an empty region as the
mouseRgn to WaitNextEvent(), it will not report mouseMoved events. But, it
seems like it reports mouseMoved events anyway. I just performed a small
test to confirm that: in System 7.5.1, calling SetEmptyRgn() on a known
good RgnHandle just before passing it to WaitNextEvent() generates
mouseMoved events left and right.

Am I dreaming? Or is this a known inaccuracy in the documentation? Are
there any other inaccuracies I should be aware of as I try to get
mouseMoved events to cooperate with me?

Email responses preferred.

Thanks.

Dan

                                                                +-+
================================================================| |=======
 \ _____ Daniel Azuma _____ \ "See what love the Father has  +--+ +--+  /
  \ <[e-mail]> \  given us, that we should be  +--+ +--+ /
   \    Caltech CS Student    \  called children of God..."     | |   /
    \  Mac Programming Artist  \            ---1 John 3:1       | |  /
    ============================================================| |===
                                                                | |
                                                                +-+

+++++++++++++++++++++++++++

>From Carl R. Osterwald <[e-mail]>
Date: 6 Sep 1995 15:35:31 GMT
Organization: National Renewable Energy Laboratory

In article <[e-mail]> Daniel
Azuma, [e-mail] writes:

>Both IM and Toolbox Assistant say that if you pass an empty region as the
>mouseRgn to WaitNextEvent(), it will not report mouseMoved events. But, it
>seems like it reports mouseMoved events anyway.

If you don't care about mouseMoved events, just use nil for the
mouseRgn. I don't know about using an empty region, I've always passed
either a real region or nil.

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro)
Date: Thu, 07 Sep 1995 16:49:20 +1200
Organization: University of Waikato

In article <42kf43$[e-mail]>, Carl R. Osterwald
<[e-mail]> wrote:

>In article <[e-mail]> Daniel
>Azuma, [e-mail] writes:
>
>>Both IM and Toolbox Assistant say that if you pass an empty region as the
>>mouseRgn to WaitNextEvent(), it will not report mouseMoved events. But, it
>>seems like it reports mouseMoved events anyway.
>
>If you don't care about mouseMoved events, just use nil for the
>mouseRgn. I don't know about using an empty region, I've always passed
>either a real region or nil.

Yup, I've noticed this behaviour, too. Empty region => mouse is never
within => continual mouse-moved events.

In any case, I think I'm moving away from mouse-moved events. I can't find
a use for them in my application framework any more, once I added support
for things like help balloons...

+++++++++++++++++++++++++++

>From [e-mail] (Daniel Azuma)
Date: Fri, 08 Sep 1995 09:52:40 -0700
Organization: California Institute of Technology, Pasadena

Carl R. Osterwald <[e-mail]> wrote:

> >Both IM and Toolbox Assistant say that if you pass an empty region as the
> >mouseRgn to WaitNextEvent(), it will not report mouseMoved events. But, it
> >seems like it reports mouseMoved events anyway.
>
> If you don't care about mouseMoved events, just use nil for the
> mouseRgn. I don't know about using an empty region, I've always passed
> either a real region or nil.

Just to clarify things...

I did finally get mouseMoved events to work.

Yes, I know I can pass NIL and not receive them at all, and that's what
I've been doing until now. But in a current project, I need to receive
mouseMoved events at certain times, and not receive them at other times.
Because of this, I was trying to simply SetEmptyRgn() on the region when I
wanted the events turned off, following IM's advice that an empty region
== no events reported. This doesn't work. So yes, now I have a slightly
uglier piece of code that checks to see whether the events should be
reported, and chooses whether to pass the region handle or NIL, and now
things are working fine.

I'm not very happy about the documentation inaccuracies. It seems to me
that if they screwed up on something as simple as this, they could screw
up in other, subtler, harder-to-deal-with ways as well.

Dan

                                                                +-+
================================================================| |=======
 \ _____ Daniel Azuma _____ \ "See what love the Father has  +--+ +--+  /
  \ <[e-mail]> \  given us, that we should be  +--+ +--+ /
   \    Caltech CS Student    \  called children of God..."     | |   /
    \  Mac Programming Artist  \            ---1 John 3:1       | |  /
    ============================================================| |===
                                                                | |
                                                                +-+

+++++++++++++++++++++++++++

>From [e-mail] (Ola Berg)
Date: 09 Sep 1995 10:11:17 GMT
Organization: Digit

Daniel Azuma ([e-mail]) wrote:

>Okay, who's experienced in working with mouse regions and mouseMoved events?

>Both IM and Toolbox Assistant say that if you pass an empty region as the
>mouseRgn to WaitNextEvent(), it will not report mouseMoved events. But, it
>seems like it reports mouseMoved events anyway.

snip!

>Email responses preferred.

No, no, no! Please answer in this group! I have many times wondered myself.
Neither InsideMac or MacProgrammer Primer explain this thouroughly.

What is happening in there??

<ixtys><

Ola
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro)
Date: Mon, 11 Sep 1995 13:14:28 +1200
Organization: University of Waikato

In article <[e-mail]>,
[e-mail] (Daniel Azuma) wrote:

>Yes, I know I can pass NIL and not receive them at all, and that's what
>I've been doing until now. But in a current project, I need to receive
>mouseMoved events at certain times, and not receive them at other times.
>Because of this, I was trying to simply SetEmptyRgn() on the region when I
>wanted the events turned off, following IM's advice that an empty region
>== no events reported. This doesn't work. So yes, now I have a slightly
>uglier piece of code that checks to see whether the events should be
>reported, and chooses whether to pass the region handle or NIL, and now
>things are working fine.

Try setting the region to one that includes (nearly) every point in the
plane, using a routine like the following:

    PROCEDURE SetFullRgn
      (
        TheRgn : RgnHandle
      );
      (* sets TheRgn to include (nearly) every point in the QuickDraw
        coordinate plane. *)

    BEGIN
      (* I don't include every point (hence the adjustments by +/-1 below),
        because it might trigger bugs in QuickDraw's region handling
        which are a fundamental consequence of the way regions are defined. *)
        SetRectRgn
          (
            (*rgn :=*) TheRgn,
            (*left :=*) MIN(ShortInt) + 1,
            (*top :=*) MIN(ShortInt) + 1,
            (*right :=*) MAX(ShortInt) - 1,
            (*bottom :=*) MAX(ShortInt)  - 1
          )
    END SetFullRgn;

+++++++++++++++++++++++++++

>From Mark Williams <[e-mail]>
Date: Sun, 10 Sep 95 08:13:12 GMT
Organization: Streetly Software


In article <[e-mail]>, Ola Berg writes:

>
> Daniel Azuma ([e-mail]) wrote:
>
> >Okay, who's experienced in working with mouse regions and mouseMoved events?
>
> >Both IM and Toolbox Assistant say that if you pass an empty region as the
> >mouseRgn to WaitNextEvent(), it will not report mouseMoved events. But, it
> >seems like it reports mouseMoved events anyway.
>
> snip!
>
> >Email responses preferred.
>
> No, no, no! Please answer in this group! I have many times wondered myself.
> Neither InsideMac or MacProgrammer Primer explain this thouroughly.
>
> What is happening in there??
>
The documentation is incorrect.

You get a mouse moved event whenever the mouse is not in the mouse region (ie it has nothing to do
with the mouse actually moving, or leaving the mouse region). For an empty region, the mouse is
never in the mouse region, so you keep getting mouse moved events.

If you dont want mouse moved events, pass 0 or a copy of the grayrgn for the mouse region.

- --------------------------------------
Mark Williams<[e-mail]>

---------------------------

>From [e-mail] (Jason Newquist)
Subject: Mac Game Gurus: Need For Errata
Date: 8 Sep 1995 06:19:48 GMT
Organization: Maxwell at UCD Physics

I've heard rumblings that there may be need for errata on the book.  Just
wondering if any of the many authors think if they're necessary or, more
to the point I suppose, when they'd be released.

Incidentally, it's a fine book.  900 pages -- wow.  And the CD looks
excellent, too.  I'm happy to support Hayden's effort for this book, and
am pleased to hear that there may be future Mac game books in the works.

Great work.

Best regards,
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Jason Newquist                          http://maxwell.ucdavis.edu/~newquist/
[e-mail]            eWorld - [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Fri, 08 Sep 1995 00:04:23 -0700
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <42ona4$[e-mail]>, [e-mail]
(Jason Newquist) wrote:

> I've heard rumblings that there may be need for errata on the book.  Just
> wondering if any of the many authors think if they're necessary or, more
> to the point I suppose, when they'd be released.
>
> Incidentally, it's a fine book.  900 pages -- wow.  And the CD looks
> excellent, too.  I'm happy to support Hayden's effort for this book, and
> am pleased to hear that there may be future Mac game books in the works.
>
> Great work.
>
> Best regards,
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Jason Newquist                          http://maxwell.ucdavis.edu/~newquist/
> [e-mail]            eWorld - [e-mail]

First of all, thanks.

I wrote one of the chapters in the book (Advanced Graphics). After it went
to press I found two errors in the code - one in the rect join code and
one in the encoded shape draw for powerPC. As soon as I have time I will
be constructing a home page -- the URL is in the book. I was intending to
have an errata page for my chapter (with code updates) there. I can't
speak for Hayden, but a central errata sheet seems like a good idea to me.

Just my thoughts

-- Mick Foley

---------------------------

>From [e-mail] (Jeff Greene)
Subject: Mac Game Programming Gurus Book
Date: Thu, 31 Aug 1995 16:55:22 -0700
Organization: University of Colorado at Boulder
   So far this book has been great, but I was wondering if there was any
way to use the CodeWarrior source code that came with the book and use it
with Symantec C++ v.7.0.4.  I have been able to convert the files to KAHL
type, but when I compile I find errors in some code that CodeWarrior
allowed.  Many of the projects also include library files (MacOS.lib) that
I can't convert or know what form to convert them to.  Am I stuck using
CodeWarrior or can anyone help me with this?  Thanks.  Email me at
[e-mail] or post here.

--
Jeff Greene                 /\                 University of Colorado
                           /  \  /\  /\              at Boulder
                          /    \/  \/  \
                         /      \  /


+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Sat, 02 Sep 1995 11:35:08 -0700
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <[e-mail]>,
[e-mail] (Jeff Greene) wrote:

>    So far this book has been great, but I was wondering if there was any
> way to use the CodeWarrior source code that came with the book and use it
> with Symantec C++ v.7.0.4.  I have been able to convert the files to KAHL
> type, but when I compile I find errors in some code that CodeWarrior
> allowed.  Many of the projects also include library files (MacOS.lib) that
> I can't convert or know what form to convert them to.  Am I stuck using
> CodeWarrior or can anyone help me with this?  Thanks.  Email me at
> [e-mail] or post here.
>
> --
> Jeff Greene                 /\                 University of Colorado
>                            /  \  /\  /\              at Boulder
>                           /    \/  \/  \
>                          /      \  /
>

Hey there --

Moving between CodeWarrior and Symantec should be possible without too
much pain.To move stuff over, create a new project in Symantec. Add all
the source files and the resource file. Set the prefix to include
MacHeaders. Add the usual Symantec libraries (I forget what they are, look
in Bullseye.π to find out). Try a compile. The errors will fall into two
catagories: compile errors and link errors. The compile errors will caused
by differences in the MacHeaders file (unrecognized system
calls/structures) or diffeences in the compilers (fairly rare). To fix the
header problems, find the missing Trap/Structure in the system headers and
include it at the top of the file. To fix the compiler problems, look at
the settings for the project - particulary pointer rules and integer size.
To fix the linker errors, find the library that has the routines that you
need and add it to the project. Converting files with assembly is harder,
but I don't think any of the code in the book has any. If it does, post
again or mail me and I'll go over it.

Enjoy the book --

Mick Foley

+++++++++++++++++++++++++++

>From [e-mail] (David Bock)
Date: 5 Sep 1995 18:08:44 GMT
Organization: Encephalon

In article <[e-mail]>,
[e-mail] (Jeff Greene) wrote:

>    So far this book has been great...


What is the exact title of the book?  Author?  Publisher?  The title alone
sounds like it would be a book I've been wishing for for a while!

-db

+++++++++++++++++++++++++++

>From [e-mail] (Mick Foley)
Date: Tue, 05 Sep 1995 19:08:40 -0700
Organization: "emf.net" Quality Internet Access.  [phone] (Voice)

In article <[e-mail]>, [e-mail]
(David Bock) wrote:

> In article <[e-mail]>,
> [e-mail] (Jeff Greene) wrote:
>
> >    So far this book has been great...
>
>
> What is the exact title of the book?  Author?  Publisher?  The title alone
> sounds like it would be a book I've been wishing for for a while!
>
> -db

The book is called "Tricks of the Mac Game Programming Gurus". It is
published by Hayden books. The book was written by many people including:
Jamie McCormick (editor), Ingemar Ragleman (lots of chapters), Steve Hales
(sound), Eric Jonston (porting), Mick Foley (advanced graphics), Jon
Benton (graphics), Stewart Cheshire (networking). There is a CD with all
the source code and other goodies as well. It is out, but many stores
haven't got it in yet. I did see it a Computer Literacy though.

Enjoy --

Mick Foley

+++++++++++++++++++++++++++

>From [e-mail] (Jay Cline)
Date: 6 Sep 1995 23:54:33 GMT
Organization: cline design

In article <[e-mail]>, [e-mail]
(David Bock) wrote:

> In article <[e-mail]>,
> [e-mail] (Jeff Greene) wrote:
>
> >    So far this book has been great...
>
>
> What is the exact title of the book?  Author?  Publisher?  The title alone
> sounds like it would be a book I've been wishing for for a while!
>
> -db
I got a copy from Barnes Nobles book store and hade them ship it to my
house, it sould be in my hands by sat.

Hayden has a Web page for it:
<http://www.mcp.com/hayden/mac_game-gurus>

The ISBN # is  1-56830-183-9

+++++++++++++++++++++++++++

>From Srdjan Mitrovic <[e-mail]>
Date: 7 Sep 1995 18:03:27 GMT
Organization: LLNL

In article <[e-mail]> Jeff
Greene, [e-mail] writes:
>Mac Game Programming Gurus Book

The Hayden Web page says that the book comes with a CD-ROM
and on the CD-ROM is Metroworks C/C++ Lite. What is the difference
between the Lite version and the full version?

                Srdjan

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Gus Zeissig)
Date: Thu, 07 Sep 1995 18:45:13 -0400
Organization: OZ Associates

In article <42nc5f$[e-mail]>, Srdjan Mitrovic
<[e-mail]> wrote:

> In article <[e-mail]> Jeff
> Greene, [e-mail] writes:
> >Mac Game Programming Gurus Book
>
> The Hayden Web page says that the book comes with a CD-ROM
> and on the CD-ROM is Metroworks C/C++ Lite. What is the difference
> between the Lite version and the full version?

The Lite version will only compile the examples in the CD-ROM, i.e., you
can't create a new project file. However, this does permit a lot of
experimentation. I have the "Secrets of the Mac Game Programming Gurus"
and it is about the most clearly written book on Mac programming I have
read ( so far, I'm only on Chap 5!). I certainly recommend it to anyone
interested in graphics, sound, file manipulation, user interface, etc. on
the Mac. I found a copy at SoftPro in Burlington, MA.

Gus Zeissig

--
No matter where you go, there you are!

+++++++++++++++++++++++++++

>From [e-mail] (Pete Fraser)
Date: Fri, 8 Sep 1995 02:25:30 GMT
Organization: very little

In article <42nc5f$[e-mail]>, Srdjan Mitrovic
<[e-mail]> wrote:

> In article <[e-mail]> Jeff
> Greene, [e-mail] writes:
> >Mac Game Programming Gurus Book
>
> The Hayden Web page says that the book comes with a CD-ROM
> and on the CD-ROM is Metroworks C/C++ Lite. What is the difference
> between the Lite version and the full version?
>
With the lite, you can't start a new project, nor can you add
files to an existing project.

--
Pete Fraser

+++++++++++++++++++++++++++

>From [e-mail] (Ron Davis)
Date: Fri, 08 Sep 1995 15:02:43 -0400
Organization: Vnet Internet Access, Charlotte, NC -  [e-mail]

In article <42nc5f$[e-mail]>, Srdjan Mitrovic
<[e-mail]> wrote:
> >Mac Game Programming Gurus Book
>
> The Hayden Web page says that the book comes with a CD-ROM
> and on the CD-ROM is Metroworks C/C++ Lite. What is the difference
> between the Lite version and the full version?
>
   I've got the book and have mostly just used my regular Codewarrior but
my understanding is the main difference is Lite doesn't allow you to
create new projects.  This allows you to use the sample code on the disk,
but you still need a real version of the program to make new stuff.

--
Ron Davis
mailto:[e-mail]
__________________________________________________________________
"I want to know God's thoughts...the rest are details."                        -- Albert Einstein
http://www.cybernetics.net/users/rdavis/home.html
Opinions are MINE - Datawatch doesn't pay me enough to own my opinions.

---------------------------

>From [e-mail] (Dave Loverink)
Subject: Mac Help Systems
Date: Tue, 05 Sep 1995 17:08:23 -0800
Organization: Xiphidus Development

I'm looking for a help system for use in a commercial product.

I have information on EHelp from MultiDoc Technologies.  Are there any
others out there that I should be considering?

Thanks in advance,

Dave Loverink
[e-mail]

 - Dave Loverink
   [e-mail]
   Xiphidus Development, a Macintosh Software Design Studio

+++++++++++++++++++++++++++

>From [e-mail] (Dave Sawyer)
Date: Wed, 06 Sep 1995 09:13:41 -0600
Organization: Education Access/Random Access, Inc.

In article <[e-mail]>,
[e-mail] (Dave Loverink) wrote:

> I'm looking for a help system for use in a commercial product.
>
> I have information on EHelp from MultiDoc Technologies.  Are there any
> others out there that I should be considering?


How about AppleGuide? It's worth considering in my opinion; it's included
with System 7.5 (and will be in all future versions of the MacOS, from
what Apple says, though it will develop even more capabilities), and it
can perform the task for the user as well as provide help.

The authoring kit is available via anonymous ftp from Apple, if you don't
mind a huge download (beware, it's over 12MB):

ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/System_Software_Extensions/Apple_Guide_Authoring_Kit.sit.hqx

Otherwise you can probably get the CD for the AppleGuide Authoring Kit for
a nominal fee. I don't have the ordering number any more, but someone else
may be able to provide it, or you can send an e-mail to
[e-mail] and they can undoubtedly tell you the
ordering procedure.

- --------------------------------------------
Dave Sawyer
Senior Systems Engineer
Education Access/Random Access, Inc. - Denver, Colorado
E-mail: [e-mail]
- --------------------------------------------
"Vex not thy employer by covering thy words with their mantle;
neither let thy employer assail thee through coveting thy words for
their mouthes. This is the path to continued gainful and profitable days"
                              - Irving, Chapter 12, Verse 32a, Rev. 1.06
- --------------------------------------------

+++++++++++++++++++++++++++

>From Jeff Benjamin <[e-mail]>
Date: 6 Sep 1995 17:37:19 GMT
Organization: StepUp Software


>>I have information on EHelp from MultiDoc Technologies.  Are there any
>>others out there that I should be considering?

You should consider Apple's System level active assistance system, Apple
Guide. See www.guideworks.com for more info.


- -----------------------------------------------
+                Jeff Benjamin
+                StepUp Software
+                [e-mail]
+                http://rampages.onramp.net/~stepup/
- -----------------------------------------------



+++++++++++++++++++++++++++

>From [e-mail] (Hisham Abboud )
Date: 6 Sep 1995 20:10:02 GMT
Organization: Netcom

In <[e-mail]>
[e-mail] (Dave Loverink) writes:
>
>I'm looking for a help system for use in a commercial product.
>
>I have information on EHelp from MultiDoc Technologies.  Are there any
>others out there that I should be considering?

I'm also looking for something like EHelp, if available.  A couple
of people suggested AppleGuide, but I suspect that Dave is like
me, looking for a WinHelp-compatible system for the Mac.  With
all due respect to AppleGuide, I personally do not have the time
to re-write the entire help system for the Mac (even though our
application was first written on the Mac then ported to Windoze).

Hisham.


+++++++++++++++++++++++++++

>From [e-mail] (Ryan Davis)
Date: Tue, 05 Sep 1995 22:50:47 -0700
Organization: Zen Spider Software

In article <[e-mail]>,
[e-mail] (Dave Loverink) wrote:

>I'm looking for a help system for use in a commercial product.
>
>I have information on EHelp from MultiDoc Technologies.  Are there any
>others out there that I should be considering?

Well, there are two others that I know about... First is Help On Wheels, a
shareware client/server type help system... I haven't used it much, so you
can form your own opinion on it... It is available at sumex/umich I
believe in the developer areas...

Second, and I will warn you, I don't like this company, is Datapak's
Online Help Construction Kit... If I were to be brief, I'd just say stay
away... If I were to be moderately long winded I'd mention their terrible
documentation, poor interface (programmer & user), bad examples, and best
of all - very RUDE customer support... If I were to be truely long winded
I'd be rated R, and this is a family show...

--
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   \   [e-mail]          \ _O_ / ...will code for food... /
    \   Smalltalk, C, & C++    \ | /                          /
     \   Mac, UNIX, & Windows   \ /       Finger for Resume  /
      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

+++++++++++++++++++++++++++

>From [e-mail] (Ross Brown)
Date: Thu, 07 Sep 1995 13:22:32 -0400
Organization: AWOL Software Productions

In article <[e-mail]>, [e-mail] (Ryan
Davis) wrote:

>In article <[e-mail]>,
>[e-mail] (Dave Loverink) wrote:
>
>>I'm looking for a help system for use in a commercial product.
>>
>>I have information on EHelp from MultiDoc Technologies.  Are there any
>>others out there that I should be considering?
>
>Well, there are two others that I know about... First is Help On Wheels, a
>shareware client/server type help system... I haven't used it much, so you
>can form your own opinion on it... It is available at sumex/umich I
>believe in the developer areas...

Thanks for the mention, Ryan.  Help on Wheels is in fact freeware, based
on the help engine which John Norstad programmed for Disinfectant.  Apart
from being free, it has some real advantages over Apple Guide:

1.  It works with any OS back to 7.0, and doesn't assume the presence of
any extensions.  You can distribute HoW for free with your product.
2.  Help files can be separate double-clickable documents, or built into
an application, control panel, or extension.  You can read them like a
book, save them as text, or print them.  An Apple Guide database does not
take the place of printed documentation, but a HoW help file certainly
can.
3.  The API is about as simple as you could want:  register, display,
deregister.  With a little extra work, you can have the help server follow
along in the background, displaying help for each user action in real
time.  A full sample application (source and binary) is included.
4.  Hypertext support includes callbacks from the help server to the
application, so "do it for me" is not out of the question.

The best way to form an opinion on HoW is to pick up the AWOL Utilities
package, and use the on-line help built into each program:

<URL:ftp://mirrors.aol.com/pub/info-mac/dev/help-on-wheels-12.hqx>
<URL:ftp://mirrors.aol.com/pub/info-mac/dev/how-developers-kit-12.hqx>
<URL:ftp://mirrors.aol.com/pub/info-mac/gui/virtual-desktop-18.hqx>
<URL:ftp://mirrors.aol.com/pub/info-mac/gui/maybe-14.hqx>
<URL:ftp://mirrors.aol.com/pub/info-mac/grf/util/pict-pocket-12.hqx>
<URL:ftp://mirrors.aol.com/pub/info-mac/dev/menu-events-12.hqx>
<URL:ftp://mirrors.aol.com/pub/info-mac/gui/menu-grabber-12.hqx>

--
Ross Brown
AWOL Software Productions
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Avi Rappoport)
Date: Thu, 07 Sep 1995 11:21:20 -0700
Organization: metrowerks, Inc.

In article <[e-mail]>, [e-mail] (Ryan
Davis) wrote:

) In article <[e-mail]>,
) [e-mail] (Dave Loverink) wrote:
)
) >I'm looking for a help system for use in a commercial product.
) >
) >I have information on EHelp from MultiDoc Technologies.  Are there any
) >others out there that I should be considering?

We are quite happy with QuickView from Altura Systems.  While it's not
perfect, it's a good solution for offering large amounts of data in
searchable hypertext.  Try www.altura.com for more info.

--
Avi Rappoport
metrowerks User Advocate & Publications Coordinator
[e-mail]             http://www.metrowerks.com/

+++++++++++++++++++++++++++

>From [e-mail] (Jordan Zimmerman)
Date: Thu, 07 Sep 1995 11:27:37 -0700
Organization: Altura Software, Inc.

> >I'm looking for a help system for use in a commercial product.
> >
> >I have information on EHelp from MultiDoc Technologies.  Are there any
> >others out there that I should be considering?

Our company, Altura Software, makes QuickHelp which is nearly 100%
compatible with WinHelp. 408-655-8005.

--
Jordan Zimmerman, Altura Software
home page: http://www.altura.com/jordanz/home.html
Coming to you fast as lightning on a 9500/120!

+++++++++++++++++++++++++++

>From [e-mail] (Ryan Davis)
Date: Wed, 06 Sep 1995 23:52:36 -0700
Organization: Zen Spider Software

In article <42km8f$[e-mail]>, Jeff Benjamin <[e-mail]>
wrote:

>>>I have information on EHelp from MultiDoc Technologies.  Are there any
>>>others out there that I should be considering?
>
>You should consider Apple's System level active assistance system, Apple
>Guide. See www.guideworks.com for more info.

Or that... (embarrassed...) I can't believe I didn't mention AppleGuide...
<sulk>

--
  -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
   \   [e-mail]          \ _O_ / ...will code for food... /
    \   Smalltalk, C, & C++    \ | /                          /
     \   Mac, UNIX, & Windows   \ /       Finger for Resume  /
      -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

+++++++++++++++++++++++++++

>From Jeff Benjamin <[e-mail]>
Date: 8 Sep 1995 06:08:25 GMT
Organization: StepUp Software

FYI -

<< real advantages over Apple Guide: It works with any OS back to 7.0>>

Apple Guide 2.0 (due RSN) will work back to 7.0.

<< You can distribute HoW for free with your product.>>

Guide files are freely distributable.

<<Help files can be separate double-clickable documents>>

There is a utility which turns Guide files into double-clickable apps (however, they do require Apple Guide).





- -----------------------------------------------
+                Jeff Benjamin
+                StepUp Software
+                [e-mail]
+                http://rampages.onramp.net/~stepup/
- -----------------------------------------------



---------------------------

>From [e-mail] (Ed Watkeys)
Subject: Programming MacTCP and Other Forms of Masochism
Date: Sat, 26 Aug 1995 17:46:53 -0400
Organization: Icognitive Systems, Inc.

Over the last month or so, I've been struggling to write correct code for
TCP/IP communications with MacTCP.

One of the fundamental problems I've faced is finding proper header files.
Checking seeding.apple.com, I notice that the lastest version of MacTCP.h
is dated mid-1994. I visit Eric Scouten's useful Mac TCP/IP FAQ and find
that he has a corrected version. Looking at John Norstad's NewsWatcher
source, I find another (significantly different) version. Which to use?

Lest one think that this problem is going away with the imminent release
of OpenTransport for non-PCI Macs, keep in mind that writing MacTCP-based
code will be necessary for the next several years, as folks with MacTCP
slowly upgrade.

Looking at some of the sample code available on the Internet (notably, the
NewsWatcher source and PowerTCP), I see coding idioms not documented
anywhere in Apple documentation (the MacTCP Programmer's Guide or the
develop 6 article). How is one to know when one's MacTCP code is finished?
When it stops crashing? Please shoot me now!

Does anyone know if the TCP/IP PowerPlant classes will materialize on the
CW7 CD? Is there any 'canonical' MacTCP source code circa 1995? Can
someone tell me why I can forget about MacTCP forever and begin coding
exclusively for OpenTransport on Monday?

Ed

--
Ed Watkeys
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (MegaWatt)
Date: Sun, 27 Aug 1995 21:34:33 GMT
Organization: University of Chicago

In article <[e-mail]>, [e-mail] (Ed Watkeys) wrote:

> Over the last month or so, I've been struggling to write correct code for
> TCP/IP communications with MacTCP.
>
> One of the fundamental problems I've faced is finding proper header files.
> Checking seeding.apple.com, I notice that the lastest version of MacTCP.h
> is dated mid-1994. I visit Eric Scouten's useful Mac TCP/IP FAQ and find
> that he has a corrected version. Looking at John Norstad's NewsWatcher
> source, I find another (significantly different) version. Which to use?
>
> Lest one think that this problem is going away with the imminent release
> of OpenTransport for non-PCI Macs, keep in mind that writing MacTCP-based
> code will be necessary for the next several years, as folks with MacTCP
> slowly upgrade.
>
> Looking at some of the sample code available on the Internet (notably, the
> NewsWatcher source and PowerTCP), I see coding idioms not documented
> anywhere in Apple documentation (the MacTCP Programmer's Guide or the
> develop 6 article). How is one to know when one's MacTCP code is finished?
> When it stops crashing? Please shoot me now!
>
> Does anyone know if the TCP/IP PowerPlant classes will materialize on the
> CW7 CD? Is there any 'canonical' MacTCP source code circa 1995? Can
> someone tell me why I can forget about MacTCP forever and begin coding
> exclusively for OpenTransport on Monday?
>
> Ed
>
> --
> Ed Watkeys
> [e-mail]

There is hope your you yet. I would try using a pre-made networking
library if you can. A couple of them exist at the moment that perform
rather well and I am in the middle of writing one myself to make it even
easier for people new to programming to TCP/IP. (My approach is unique
from the existing ones... stay posted for further details in the next
month or so)

If you feel you must write your own, then follow the examples that are out
there and when you run into a knotty problem, ask some specific questions.
You'll get by ok. After a little while, most of the coding idioms seem
aparent.


P.S.  Yes that was shameless advertising above about my networking class
library called NetStream (mostly for TCP/IP)... it isn't even in beta
yet.  (Sounds just like Microsoft)

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro)
Date: Mon, 28 Aug 1995 16:53:48 +1200
Organization: University of Waikato

In article <[e-mail]>, [e-mail] (Ed Watkeys) wrote:

>One of the fundamental problems I've faced is finding proper header files.
>Checking seeding.apple.com, I notice that the lastest version of MacTCP.h
>is dated mid-1994. I visit Eric Scouten's useful Mac TCP/IP FAQ and find
>that he has a corrected version. Looking at John Norstad's NewsWatcher
>source, I find another (significantly different) version. Which to use?

I found a reasonably up-to-date version on a recent developer CD (or maybe
it was the MacOS SDK). In the process of adapting that to Modula-2, I
found an incorrect pad byte, which I removed. That adaptation has been
working OK for me so far.

If someone would like to post the differences between the above
interfaces, I'm sure we could pick them apart here.

>Looking at some of the sample code available on the Internet (notably, the
>NewsWatcher source and PowerTCP), I see coding idioms not documented
>anywhere in Apple documentation (the MacTCP Programmer's Guide or the
>develop 6 article). How is one to know when one's MacTCP code is finished?
>When it stops crashing? Please shoot me now!

Well, "When it stops crashing" has served me in developing other kinds of
Mac software before now. :-)

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Sat, 02 Sep 1995 00:23:22 +0800
Organization: Stairways Software

>In article <[e-mail]>, [e-mail] (Ed Watkeys)
wrote:
>
>> Looking at some of the sample code available on the Internet (notably, the
>> NewsWatcher source and PowerTCP), I see coding idioms not documented
>> anywhere in Apple documentation (the MacTCP Programmer's Guide or the
>> develop 6 article). How is one to know when one's MacTCP code is finished?
>> When it stops crashing? Please shoot me now!

It's actually fairly easy to avoid MacTCP crashing.  Primary rules:

You can't abort a DNS lookup.  If one is in progress, then you can let the
user "cancel" it, but you must allow it to continue until it returns with
an error or an answer.  Obviously, you cannot quit during this time.

You can't abort an ICMP ping.  See above.

For every TCP/UDP connection you successfully Create, you *must* Release
it exactly once.  This will terminate all async calls on this connection.

That's pretty much it.  If you avoid doing any of those, it wont crash
unless you fail similar rules to that which would be used with the file
system for example (ie, your completion routines may be called before your
async call returns, your completions routines can't do lots of things, you
can't release memory while it's in use, or reuse control blocks, etc).

Enjoy,
   Peter.
--
"there is no significant correlation to violence on TV and agression in
daily life" - NHR Broadcasting Culture Research Institute in Tokyo.

+++++++++++++++++++++++++++

>From [e-mail] (Mike Crawford)
Date: 5 Sep 1995 19:48:27 GMT
Organization: UC Santa Cruz - SCIPP

>>In article <[e-mail]>, [e-mail] (Ed Watkeys)
>wrote:
>>> develop 6 article). How is one to know when one's MacTCP code is finished?
>>> When it stops crashing? Please shoot me now!

It's been a long time since I worked on MacTCP, so forgive me if I am a little
vague here.

When an application starts using MacTCP, the application allocates a buffer
and passes it into MacTCP, I think in the Open call.

MacTCP uses that buffer for I/O.  When a packet comes in, it is written into
the buffer you have allocated.  One advantage of this is that an application
has some control over its buffering; in principle allocating a bigger buffer
allows you better performance, or at least prevents having to throttle the
TCP stream as much.

The problem is that a common error during development can screw you in a
really subtle way if you don't know about it.  You must release your TCP
streams in order for MacTCP to stop using that buffer.  MacTCP knows nothing
of processes.  It will still use the buffer after your application quits!

The MacOS knows to close an application's files when the app quits.  On
Unix, both files and TCP connections are file descriptors that are kept on
the process data structure in the kernel, so the Unix OS knows to close your
network connections for you when you quit.  The Mac does not do this when
you quit.

What will happen is that the now-invalid region of memory will still be
written to and read from MacTCP.  Eventually you will launch another
application that uses that same region of memory.  A network packet
will arrive, and scrawl garbage over your heap.  You are dead meat.

For this reason, _never_ call ExitToShell directly from a program that
uses MacTCP.  Write a wrapper, called, say "MyExitToShell".  MyExitToShell
will ensure that all the streams have been released and then do an
ExitToShell.  Keep some record in the structures you use for streams that
indicates whether the stream has been released.  When you release a stream,
either mark it shut or release the structure you associate with it, and
at the exit of your program, MyExitToShell can make sure they are all
really closed whether you are quitting normally or due to some emergency.

This also applies if you force-quit or ES an application with Macsbug.  If
you quit an app, say because the net was hung up, immediately restart
your Macintosh.

I tested MacTCP for Apple back in 1990.  We had a lot of trouble with the
test tool.  One of the problems was that the tool would sometimes abort
without closing a stream, and the next test run would crash.  This made
it hard to qualify MacTCP.  Fixing this in the tool really made the
"test" appear more stable.


--
Mike Crawford                      One in forty Americans believe that they
[e-mail]              have been abducted by aliens.
[e-mail]          <-- Finger Me here for PGP Public Key
http://www.scruznet.com/~crawford/ (under construction; foundation poured.)

+++++++++++++++++++++++++++

>From [e-mail] (chris-b)
Date: Mon, 11 Sep 1995 17:04:37 +1200
Organization: HyperMedia Unit, Comp Sci, Auckland University

In article <42i9ib$[e-mail]>, [e-mail] (Mike
Crawford) wrote:

>The problem is that a common error during development can screw you in a
>really subtle way if you don't know about it.  You must release your TCP
>streams in order for MacTCP to stop using that buffer.  MacTCP knows nothing
>of processes.  It will still use the buffer after your application quits!
>
>The MacOS knows to close an application's files when the app quits.  On
>Unix, both files and TCP connections are file descriptors that are kept on
>the process data structure in the kernel, so the Unix OS knows to close your
>network connections for you when you quit.  The Mac does not do this when
>you quit.
>
>What will happen is that the now-invalid region of memory will still be
>written to and read from MacTCP.  Eventually you will launch another
>application that uses that same region of memory.  A network packet
>will arrive, and scrawl garbage over your heap.  You are dead meat.

For MacTCP developers - get the extension "ZapTCP 1.2". It keeps track of
streams opened from within an application and aborts & releases them if
the app crashes.

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

---------------------------

>From [e-mail] (WINTER  PAUL RUDOLPH)
Subject: Using two different fonts in a dialog box?
Date: 22 Aug 95 15:08:15 GMT
Organization: University of Colorado at Boulder

I would like to open a dialog box with only static text items and a couple
of buttons (Return and Cancel).  I would like all of the static text items
to be in the default font but two.  I want these two to be smaller size and
a different font.  How do I go about changing the font for just these two
items.  I have been mucking around with calls to GetFontNum and then doing
a call to TextFont(newfontnum), but all that does is change the font that
is used in window titles on the desktop.  I have been checking the system
and application fonts with GetSysFont and GetAppFont both before and after
my calls to TextFont, but I've noticed no changes in these values from before
the call to after the call.


Obviously, I'm overlooking something here, as I have seen programs that do
this.  Could someone point me in the right direction?  Also, could someone
explain to me what TextFont is supposed to do?

Thanks in advance.

Paul Winter


+++++++++++++++++++++++++++

>From Charles B. Cranston <[e-mail]>
Date: 22 Aug 1995 19:40:13 GMT
Organization: Network Infrastructures UMD CSC

In article <[e-mail]>
WINTER  PAUL RUDOLPH, [e-mail] writes:

> I would like to open a dialog box with only static text items and a couple
> of buttons (Return and Cancel).  I would like all of the static text items
> to be in the default font but two.  I want these two to be smaller size and
> a different font.

I guess conceptually the easiest way to do this is to do
your text drawing from a user item.  That way your callback
routine gets control every time the dialog is redrawn, and
you can change fonts and typesizes etc to your heart's content.

*DONT FORGET TO SAVE AND RESTORE THE PEN STATE*

Well, maybe that's a little harsh.  But it does look weird if
you set a thickness-3 pen (like, to make a default OK button)
and the dialog has more drawing to do!!!  :-)

+-+-+
Charles B. (Ben) Cranston <[e-mail]>
http://www.wam.umd.edu/~zben

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Larson)
Date: 23 Aug 1995 16:22:48 GMT
Organization: UCLA, Computer Science Department

In article <[e-mail]> [e-mail] (WINTER  PAUL RUDOLPH) writes:
>I would like to open a dialog box with only static text items and a couple
>of buttons (Return and Cancel).  I would like all of the static text items
>to be in the default font but two.  I want these two to be smaller size and
>a different font.  How do I go about changing the font for just these two
>items. [ ... ]

Look into using an 'ictb' resource. I _believe_ it lets you set the font
for individual dialog items (could be wrong though). They are documented
in Inside Macintosh: Macintosh Toolbox Essentials.

--Chris
_______________________________________________________________________________
Chris Larson -- Amateur Macintosh Geek, CoBase Research Assistant
L.A. Institute of Slowly and Painfully Working Out the Surprisingly Obvious
- -------------------------------------+---------------------------------------
(Insert Disclaimer Here)               | Who's the man ridin' in the sun?
UCLA Bruins--1995 NCAA Men's Basketball| Who's the man with the itchy gun?
             National Champions (yea!) | Who's the man who kills for fun?
Internet: [e-mail]  | Psycho Dad, Psycho Dad, PSYCHO DAD!

+++++++++++++++++++++++++++

>From [e-mail] (Steve Caine)
Date: Thu, 24 Aug 1995 02:56:02 GMT
Organization: The World @ Software Tool & Die

In article <41fkko$[e-mail]>, [e-mail]
(Christopher Larson) wrote:

> In article <[e-mail]>
[e-mail] (WINTER  PAUL RUDOLPH) writes:
> >I would like to open a dialog box with only static text items and a couple
> >of buttons (Return and Cancel).  I would like all of the static text items
> >to be in the default font but two.  I want these two to be smaller size and
> >a different font.  How do I go about changing the font for just these two
> >items. [ ... ]
>
> Look into using an 'ictb' resource. I _believe_ it lets you set the font
> for individual dialog items (could be wrong though). They are documented
> in Inside Macintosh: Macintosh Toolbox Essentials.
>
> --Chris

The best way to create 'ictb' resources is with the resource editor
Resorceror from Mathemaesthetics. It provides a visual editor for creating
dialogs that lets you specify font, typeface (plain/bold/italic, etc.) and
color for dialog text items and colors for controls, and a "Try Out"
option that runs the dialog as if your code were displaying it, so you can
click on buttons, radio and checkboxes, popup menus etc. to see how it
appears to the user.

--
Steve Caine

+++++++++++++++++++++++++++

>From [e-mail] (Ross Mallett)
Date: Thu, 07 Sep 1995 01:17:01 +1200
Organization: The Lamb and Flag

In article <[e-mail]>,
[e-mail] (WINTER  PAUL RUDOLPH) wrote:

> I would like to open a dialog box with only static text items and a couple
> of buttons (Return and Cancel).  I would like all of the static text items
> to be in the default font but two.  I want these two to be smaller size and
> a different font.  How do I go about changing the font for just these two
> items?  I have been mucking around with calls to GetFontNum and then doing
> a call to TextFont(newfontnum), but all that does is change the font that
> is used in window titles on the desktop.  I have been checking the system
> and application fonts with GetSysFont and GetAppFont both before and after
> my calls to TextFont, but I've noticed no changes in these values from before
> the call to after the call.
>
>
> Obviously, I'm overlooking something here, as I have seen programs that do
> this.  Could someone point me in the right direction?  Also, could someone
> explain to me what TextFont is supposed to do?
>
TextFont resets the current grafPort's font to the given font number. My
guess is that your dialog was not the current grafPort when you called
TextFont.

Even if it was, this would not solve your problem really, because you
don't want all the items in your dialog in that font, only two of them.

I would suggest using userItems in the dialog to draw the text the way you
want. The routine would look something like this (NB: the dialog manager
would have already called SetPort for you):

pascal void MyDraw(DialogPtr theDialog, short theItem)

   {
   short    itemType;
   Rect     itemRect;
   Handle   itemHandle;

   GetDItem(theDialog,theItem,&itemType,&itemHandle,&itemRect);
   TextFont(monaco);
   TextSize((short) 9);
   TextBox(itemText,(long) strlen(itemText), &itemRect, teJustRight);
   }

You have to install a userItem before you show the dialog. eg.

void DoMyDialog()

   {
   DialogPtr myDialog;
   short     itemType;
   short     itemHit;
   Rect      itemRect;
   Handle    itemHandle;

   myDialog = GetNewDialog(myDialogID,NULL, (WindowPtr) -1); /* Invisible!! */
   GetDItem(myDialog,2,&itemType,&itemHandle,&itemRect);
   SetDItem(myDialog,2,itemType,(Handle) MyDraw,&itemRect);
   ShowWindow(myDialog); /* NOW make it visible */
   do modalDialog(NULL,&itemHit) while(itemHit != ok);
   }

All this information about userItems (and more) can be found in Technical
Note #34.

If there's an easier way *I'd* like to know about it.

+++++++++++++++++++++++++++

>From [e-mail] (Resorcerer)
Date: 7 Sep 1995 12:18:07 -0400
Organization: America Online, Inc. (1-800-827-6364)

>>If there's an easier way *I'd* like to know about it.

The Dialog Manager already supports separate text styles and colors
for individual dialog items.  You have to create an 'ictb' resource with
entries for the corresponding dialog items to which you want to give
custom styles.

Resorcerer lets you do this easily and directly within its Dialog
Editor.  Just select the two items that you want to appear in
a different font and choose a menu command to bring up the
styles and colors dialog.

There are three drawbacks to using the 'ictb' resource method.
The first is that it won't work on any machine that doesn't
have Color Quickdraw installed.  This isn't that big a deal
anymore.  Another problem is that AppendDITL and other
item list routines introduced in System 7 don't know about
'ictb's, so their use can get the Dialog Manager confused as
to which entry in the 'ictb' belongs to which item.  If you're
not using these routines, it shouldn't be a problem.  A third
drawback is if you use a wierd text font, you can't
be guaranteed that the same font will be on your user's
machine.  Most of the time this isn't a problem, since people
typically use custom text styles to draw text in a "small
system font", such as Geneva 9 (bold).

If you don't want to use the 'ictb' method, then the next
best method IMO is to create a 'PICT' the displays precisely
the text in the font you want.  Then create a Picture dialog
item that refers to it.  That way, you don't have to worry about
whether your user has the font installed or not, yet your
application is still able to be localized with a resource editor.
This only works if the 'PICT' is a true pixmap screen-copy,
as opposed to the kind that has the text and font information
embedded in it (Resorcerer let's you create both 'PICT' types).

The install-a-user-item-draw-routine method would be my
last choice, since it is the least flexible.

Doug McKenna
Mathemaesthetics, Inc.
Developers of Resorcerer

+++++++++++++++++++++++++++

>From [e-mail] (Chris Watson)
Date: Sat, 09 Sep 1995 01:51:25 -0400
Organization: Communications Accessibles Montreal, Quebec Canada

In article <hawkeye-0709950117020001@202.12.90.8>,
[e-mail] (Ross Mallett) wrote:

> If there's an easier way *I'd* like to know about it.

I think the easiest way to change the static text fonts in a dialogue are
to include an 'ictb' resource for that dialogue (I think you'll also need
an 'dctb' resource)  Some programs, not ResEdit, have dialogue editors
that allow you to change the font very easily.... All the resources are
created for you... Resorceror and AppMaker can both do this, for example.

========================================================================
  C C      |                   |                                       |
  | |      | Chris Watson      |   "Huked on phoniks wurks fer me!"    |
H-C-C-O-H  | [e-mail]   |       - American television           |
  | |      | Montreal, Canada  |                                       |
  C C      |                   |                                       |
========================================================================

---------------------------

End of C.S.M.P. Digest
**********************